Files that changed from the base of the PR and between bdda21f and 87751ac.

• x/auth/proto/buf.lock is excluded by !**/*.lock
• x/auth/types/accounts.pb.go is excluded by !**/*.pb.go

• .github/CODEOWNERS (2 hunks)
• .github/pr_labeler.yml (1 hunks)
• CHANGELOG.md (2 hunks)
• UPGRADING.md (4 hunks)
• api/cosmos/auth/v1beta1/accounts.pulsar.go (16 hunks)
• api/cosmos/tx/config/v1/config.pulsar.go (2 hunks)
• api/cosmos/validate/module/v1/module.pulsar.go (1 hunks)
• proto/cosmos/tx/config/v1/config.proto (0 hunks)
• proto/cosmos/validate/module/v1/module.proto (1 hunks)
• simapp/app_config.go (3 hunks)
• simapp/simd/cmd/testnet_test.go (1 hunks)
• simapp/v2/app_config.go (3 hunks)
• tests/e2e/auth/keeper/app_config.go (1 hunks)
• tests/e2e/baseapp/block_gas_test.go (1 hunks)
• tests/integration/bank/app_test.go (1 hunks)
• tests/integration/distribution/appconfig.go (1 hunks)
• tests/integration/evidence/app_config.go (1 hunks)
• tests/integration/mint/app_config.go (1 hunks)
• tests/integration/protocolpool/app_config.go (1 hunks)
• tests/integration/runtime/query_test.go (1 hunks)
• tests/integration/server/grpc/out_of_gas_test.go (1 hunks)
• tests/integration/server/grpc/server_test.go (1 hunks)
• tests/integration/slashing/app_config.go (1 hunks)
• tests/integration/slashing/slashing_test.go (1 hunks)
• tests/integration/staking/app_config.go (1 hunks)
• testutil/configurator/configurator.go (2 hunks)
• testutil/types.go (1 hunks)
• x/README.md (1 hunks)
• x/accounts/defaults/base/account.go (1 hunks)
• x/auth/keeper/grpc_query.go (1 hunks)
• x/auth/proto/buf.gen.gogo.yaml (0 hunks)
• x/auth/proto/buf.gen.pulsar.yaml (0 hunks)
• x/auth/proto/buf.yaml (0 hunks)
• x/auth/tx/README.md (2 hunks)
• x/auth/tx/config/depinject.go (3 hunks)
• x/tx/README.md (5 hunks)
• x/validate/README.md (1 hunks)
• x/validate/depinject.go (1 hunks)
• x/validate/keys.go (1 hunks)
• x/validate/module.go (1 hunks)

• proto/cosmos/tx/config/v1/config.proto
• x/auth/proto/buf.gen.gogo.yaml
• x/auth/proto/buf.gen.pulsar.yaml
• x/auth/proto/buf.yaml

• .github/CODEOWNERS
• api/cosmos/tx/config/v1/config.pulsar.go
• api/cosmos/validate/module/v1/module.pulsar.go
• x/README.md
• x/accounts/defaults/base/account.go
• x/validate/keys.go
• x/validate/module.go

proto/cosmos/validate/module/v1/module.proto (2)

8-12: LGTM!

The introduction of the Module message as a configuration object for the x/validate module is a great addition. It enhances the modularity and reusability of validation logic within the Cosmos SDK.

---

5-5: Verify the import statement.

The static analysis tool has flagged the import statement import "cosmos/app/v1alpha1/module.proto"; indicating that the file does not exist.

Please verify if the file exists at the specified path and make necessary corrections if required.

Verification successful

---

Import statement verified: File exists with a slight path difference

The imported file cosmos/app/v1alpha1/module.proto exists in the repository, but it's located at proto/cosmos/app/v1alpha1/module.proto. The current import statement might work as-is, depending on how import paths are resolved in your project. However, you may want to consider updating the import statement to include the proto/ prefix for consistency.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify if the imported file exists.

# Test: Check if the file exists. Expect: File found.
fd --no-ignore --type file --full-path "cosmos/app/v1alpha1/module.proto"

Length of output: 112

Tools

buf

5-5: import "cosmos/app/v1alpha1/module.proto": file does not exist

(COMPILE)

tests/integration/mint/app_config.go (1)

22-22: Excellent addition of the validation module to the application configuration!

The inclusion of configurator.ValidateModule() in the AppConfig initialization is a great step towards enhancing the robustness and integrity of the application. This module will likely be responsible for validating transactions and other operations, rejecting any invalid ones and maintaining data correctness.

This change aligns with the best practice of validating inputs and ensuring data integrity in the application. Well done!

tests/e2e/auth/keeper/app_config.go (1)

23-23: LGTM! The addition of the ValidateModule() enhances the application's configuration management.

The inclusion of the configurator.ValidateModule() in the AppConfig variable initialization is a positive change that aligns with the PR objectives of introducing the new x/validate module. This addition incorporates validation capabilities into the application's configuration, ensuring that the settings adhere to expected formats and constraints. By validating the configuration, the application can potentially prevent runtime errors related to misconfigured settings, thereby improving its overall robustness and reliability.

tests/integration/evidence/app_config.go (1)

24-24: LGTM!

The addition of configurator.ValidateModule() to the AppConfig variable initialization is a positive change that enhances the application's configuration management process by integrating validation capabilities. This change is likely to improve the application's robustness by ensuring that the configuration adheres to certain rules or constraints, thereby maintaining data integrity and correctness.

The change is well-integrated into the existing code and is unlikely to have any negative impact on the application's functionality.

testutil/types.go (1)

7-26: LGTM! The addition of the new module name constant and the formatting enhancements improve the codebase.

The introduction of the ValidateModuleName constant suggests an expansion of the SDK's capabilities, potentially adding new validation functionalities. This change aligns with the PR objectives mentioned in the summary.

The reformatting of the module name constants enhances the readability and maintainability of the code, making it easier for developers to reference and utilize these constants across the SDK.

Great work on improving both the functionality and the code quality!

tests/integration/protocolpool/app_config.go (1)

24-24: LGTM!

The addition of configurator.ValidateModule() to the AppConfig variable initialization is a positive change that aligns with the PR objective of introducing the x/validate module to improve the validation process within the SDK. This change enhances the application's robustness by incorporating validation logic into its configuration.

tests/integration/distribution/appconfig.go (1)

24-24: Approve the addition of the validation module.

The introduction of the ValidateModule() in the AppConfig initialization is a good practice, as it can help ensure that configurations adhere to specified rules or constraints, potentially improving robustness and error handling.

Please verify if there are any dependencies or downstream impacts of adding this module. Consider running the following script to search for potential usage or references to the ValidateModule() across the codebase:

Verification successful

---

Confirm the addition of ValidateModule() as consistent and appropriate

The addition of configurator.ValidateModule() in the AppConfig initialization is consistent with the usage pattern observed across multiple test files and app configurations in the codebase. This module appears to be a standard component in the setup process for tests and possibly for the actual application.

Given its widespread use and consistent integration alongside other modules, it's unlikely to introduce any unexpected behavior or have negative downstream impacts. The change aligns with the existing practices in the codebase.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for usage or references to the `ValidateModule()` 
rg --type go -i -C 5 'ValidateModule\(\)'

Length of output: 11315

tests/integration/staking/app_config.go (1)

25-25: LGTM! The addition of the validation module is a positive change.

The introduction of the configurator.ValidateModule() in the AppConfig is a straightforward and beneficial modification. This module is likely to improve the application's error handling and ensure data integrity by validating certain aspects of its operation.

The change enhances the overall robustness of the application without introducing any apparent issues or complexities.

tests/integration/slashing/app_config.go (1)

26-26: LGTM! The addition of the ValidateModule enhances the application's robustness.

The inclusion of the configurator.ValidateModule() in the AppConfig is a positive change that strengthens the application's validation capabilities. This module will likely ensure that transactions and states within the application adhere to specified rules and constraints, thereby maintaining data integrity and correctness.

By integrating this validation module into the application's configuration, error handling and validation processes during runtime should be improved. This proactive approach enhances the overall robustness of the application.

x/validate/README.md (4)

1-8: The module description is clear and informative.

The overview of the x/validate module effectively communicates its purpose and key features. It clearly explains how the module facilitates the setup of ante/post handlers and global transaction validators in runtime applications, and how it leverages dependency injection to automatically integrate these components.

Tools

LanguageTool

[uncategorized] ~4-~4: Use a comma before ‘and’ if it connects two independent clauses (unless they are closely connected and short).
Context: ...quired when using runtime and runtime v2 and you want to make use of the pre-defined...

(COMMA_COMPOUND_SENTENCE)

---

[uncategorized] ~7-~7: Possible missing comma found.
Context: ...dators. ::: The x/validate is an app module solely there to setup ante/post handler...

(AI_HYDRA_LEO_MISSING_COMMA)

---

9-24: The "Extra TxValidators" section provides valuable guidance.

The section offers a clear explanation of how developers can add extra transaction validators to their application, along with a relevant example use case. The included code snippet is a helpful reference for configuring custom validators using depinject in the app.go file.

---

26-35: The "Storage" section provides essential information.

The section clearly communicates that the x/validate module does not have a store key and reminds developers to include the module name in the SkipStoreKeys runtime config. The provided code snippet is a helpful reference for correctly adding the module name to the SkipStoreKeys array.

---

7-7: Ignore the static analysis hint about a missing comma.

The hint suggesting a possible missing comma in the sentence "The x/validate is an app module solely there to setup ante/post handlers on a runtime app (via baseapp options) and the global tx validators on a runtime/v2 app (via app module)." is a false positive. The sentence is a single independent clause with multiple prepositional phrases, and there is no grammatical requirement for a comma in this structure. Adding a comma may actually disrupt the flow and readability of the sentence.

Tools

LanguageTool

[uncategorized] ~7-~7: Possible missing comma found.
Context: ...dators. ::: The x/validate is an app module solely there to setup ante/post handler...

(AI_HYDRA_LEO_MISSING_COMMA)

.github/pr_labeler.yml (1)

83-84: LGTM!

The addition of the C:x/validate label for the x/validate/**/* path aligns with the PR objective of introducing the new x/validate module. This change enhances the existing labeling structure by ensuring that contributions to the validation aspect of the project can be easily identified and managed.

simapp/simd/cmd/testnet_test.go (1)

37-37: LGTM!

The addition of configurator.ValidateModule() to the list of modules being configured for the test is a positive change. It ensures that the new x/validate module is included in the test setup, which aligns with the PR objective and enhances the robustness of the tests.

tests/integration/server/grpc/out_of_gas_test.go (1)

48-48: Enhancing test suite with validation capabilities

The addition of configurator.ValidateModule() to the list of modules being initialized in the SetupSuite function is a positive change that improves the robustness of the integration tests. By incorporating validation capabilities, the test suite can now cover scenarios that involve validation checks on transactions or operations. This change aligns with best practices of comprehensive testing and enhances the overall quality of the test suite.

tests/integration/runtime/query_test.go (1)

49-49: LGTM! The addition of the validation module enhances the integration tests.

The inclusion of configurator.ValidateModule() in the test fixture setup aligns with the PR objective of introducing the new x/validate module to improve the validation process within the SDK.

This change could enable more comprehensive testing scenarios that verify certain conditions or constraints are met during test execution, thereby improving the robustness and reliability of the integration tests.

tests/integration/slashing/slashing_test.go (1)

70-70: LGTM! Adding validation to the test setup is a good enhancement.

Including the ValidateModule in the app configuration for the integration test is a positive change. It ensures that the slashing messages being tested adhere to the expected validation rules, thereby improving the robustness and reliability of the tests. Catching any validation issues early in the testing phase helps maintain a high quality codebase.

The TestSlashingMsgs function provides sufficient coverage for the core slashing messages (MsgCreateValidator and MsgUnjail). It tests the success scenario of creating a validator and the failure scenario of unjailing an unknown validator, covering the key functionalities.

tests/e2e/baseapp/block_gas_test.go (1)

91-91: LGTM!

The addition of the ValidateModule to the app configuration is a good change. It ensures that the validation functionality is available for use in the tests, thereby improving the robustness and reliability of the test suite.

x/auth/keeper/grpc_query.go (2)

234-234: Verify that the Base field provides the necessary account information.

The condition for checking account existence has been updated to use xAccount.Base instead of xAccount.Info. Ensure that the Base field contains all the required account information for the desired functionality.

---

237-237: Ensure that the Base field contains the expected account details.

The response now returns xAccount.Base instead of xAccount.Info. Verify that the Base field provides all the necessary account information expected by the calling code.

x/auth/tx/README.md (3)

80-87: LGTM!

The "Storage" section provides clear information about the module's lack of a store key and includes a helpful code snippet to illustrate the configuration of SkipStoreKeys. The changes in this section are accurate and informative.

---

Line range hint 88-137: LGTM!

The "CLI" section is well-documented and provides detailed information about the CLI commands for querying transactions and blocks. The examples are clear and cover various scenarios, making it easy for users to understand and use the CLI commands effectively. The changes in this section are comprehensive and informative.

Tools

LanguageTool

[grammar] ~76-~76: The verb after “to” should be in the base form as part of the to-infinitive. A verb can take many forms, but the base form is always used in the to-infinitive.
Context: ...ject module. The depinject module is to outputs the TxConfig and TxConfigOptions fo...

(TO_NON_BASE)

---

Line range hint 138-235: LGTM!

The "gRPC" section provides detailed information about the gRPC endpoints for encoding and decoding transactions. The examples are well-documented and include sample requests and responses, making it easy for users to understand and interact with the gRPC endpoints. The changes in this section are comprehensive and informative.

Tools

Markdownlint

23-23: Expected: 4; Actual: 2
Unordered list indentation

(MD007, ul-indent)

---

24-24: Expected: 4; Actual: 2
Unordered list indentation

(MD007, ul-indent)

---

25-25: Expected: 4; Actual: 2
Unordered list indentation

(MD007, ul-indent)

---

26-26: Expected: 8; Actual: 4
Unordered list indentation

(MD007, ul-indent)

---

27-27: Expected: 8; Actual: 4
Unordered list indentation

(MD007, ul-indent)

---

28-28: Expected: 8; Actual: 4
Unordered list indentation

(MD007, ul-indent)

---

29-29: Expected: 4; Actual: 2
Unordered list indentation

(MD007, ul-indent)

---

30-30: Expected: 8; Actual: 4
Unordered list indentation

(MD007, ul-indent)

---

31-31: Expected: 4; Actual: 2
Unordered list indentation

(MD007, ul-indent)

---

32-32: Expected: 8; Actual: 4
Unordered list indentation

(MD007, ul-indent)

---

33-33: Expected: 12; Actual: 6
Unordered list indentation

(MD007, ul-indent)

---

34-34: Expected: 12; Actual: 6
Unordered list indentation

(MD007, ul-indent)

---

35-35: Expected: 12; Actual: 6
Unordered list indentation

(MD007, ul-indent)

---

36-36: Expected: 12; Actual: 6
Unordered list indentation

(MD007, ul-indent)

---

37-37: Expected: 8; Actual: 4
Unordered list indentation

(MD007, ul-indent)

---

38-38: Expected: 12; Actual: 6
Unordered list indentation

(MD007, ul-indent)

---

39-39: Expected: 12; Actual: 6
Unordered list indentation

(MD007, ul-indent)

---

40-40: Expected: 12; Actual: 6
Unordered list indentation

(MD007, ul-indent)

---

41-41: Expected: 12; Actual: 6
Unordered list indentation

(MD007, ul-indent)

tests/integration/server/grpc/server_test.go (1)

59-59: LGTM! The addition of the ValidateModule aligns with the PR objectives.

The inclusion of the configurator.ValidateModule() in the test suite setup is a positive change that incorporates validation functionality into the testing framework. This addition has the potential to enhance the robustness of the tests by ensuring data integrity and correctness.

simapp/app_config.go (4)

31-31: LGTM!

The import statement for the validatemodulev1 module is correctly added.

---

73-78: LGTM!

The import statements for the authtxconfig and validate modules are correctly added.

---

186-187: LGTM!

Adding the authtxconfig.DepinjectModuleName and validate.ModuleName to the SkipStoreKeys list is a valid configuration for modules that do not require a store key.

---

191-198: LGTM!

The module configurations for the authtxconfig.DepinjectModuleName and validate.ModuleName modules are correctly added.

• The authtxconfig.DepinjectModuleName module is configured as a depinject module to provide transaction configuration.
• The validate.ModuleName module is configured as an application module for validation functionality.

These configurations align with the overall changes to integrate the x/validate module and refactor the transaction configuration.

simapp/v2/app_config.go (4)

31-31: LGTM!

The import statement for the validation module is correctly added.

---

72-73: LGTM!

The import statement for the authtxconfig module is correctly added.

---

188-193: LGTM!

The SkipStoreKeys field is correctly updated to include the authtxconfig.DepinjectModuleName and validate.ModuleName. This change aligns with the design decision to streamline the module's interaction with the state store.

---

196-203: LGTM!

The new entries in the configuration list correctly integrate the authtxconfig.DepinjectModuleName and validate.ModuleName modules with their respective configurations. These changes enhance the application's modularity by incorporating validation capabilities and refining transaction handling.

testutil/configurator/configurator.go (2)

198-205: LGTM!

The ValidateModule function correctly registers the validation module and wraps its configuration using the appconfig.WrapAny function. The module name is defined in the testutil package, which is a good practice for consistency. The function follows the same pattern as other module configuration functions in the file.

---

191-195: Verify the module name change in the codebase.

The TxModule function correctly registers the transaction module and wraps its configuration using the appconfig.WrapAny function. The module name has been changed to indicate a shift in focus towards the authentication transaction configuration. The function follows the same pattern as other module configuration functions in the file.

Run the following script to verify the module name usage:

Verification successful

---

Module name change verified and properly implemented.

The change from testutil.TxModuleName to testutil.AuthTxConfigDepinjectModuleName has been successfully implemented:

1. The old module name has been completely removed from the codebase.
2. The new module name is used consistently in the testutil/configurator/configurator.go file.
3. The constant AuthTxConfigDepinjectModuleName is properly defined in testutil/types.go with the value "tx".

The change appears to be isolated to the specific file under review, and there are no unexpected usages of the new module name throughout the codebase. The TxModule() function, which is used in various test configurations, is not directly affected by this change.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all references to the transaction module match the new name.

# Test: Search for the old module name. Expect: No occurrences.
rg --type go $'testutil\.TxModuleName'

# Test: Search for the new module name. Expect: Only occurrences in the intended locations.
rg --type go $'testutil\.AuthTxConfigDepinjectModuleName'

Length of output: 321

---

Script:

#!/bin/bash
# Description: Further verify the transaction module references and constant definition

# Search for any references to 'tx' or 'transaction' module
rg --type go -i '(tx|transaction).*module'

# Look for the definition of the new module name constant
rg --type go 'AuthTxConfigDepinjectModuleName\s*='

# Check for any remaining references to 'TxModule' function or variable
rg --type go 'TxModule'

Length of output: 85159

tests/integration/bank/app_test.go (1)

100-100: LGTM! The addition of ValidateModule enhances the test suite.

The inclusion of configurator.ValidateModule() in the test suite configuration is a positive change that is likely to improve the robustness of the testing process by incorporating validation functionalities. This addition follows the existing pattern of module configuration and is placed appropriately in the list of configurations passed to simtestutil.SetupWithConfiguration.

api/cosmos/auth/v1beta1/accounts.pulsar.go (2)

375-375: LGTM!

The renaming of the Account field to Base enhances clarity and aligns with the BaseAccount type. The updated comments also provide better context for the field's purpose. The changes are consistent across the struct and its methods.

Also applies to: 943-944, 996-999

---

973-977: LGTM!

The GetBase method has been appropriately updated to return the Base field, aligning with the struct field renaming. The logic remains unchanged.

x/auth/tx/config/depinject.go (3)

28-29: Module Name Definition is Clear and Correct

The DepinjectModuleName constant is appropriately defined and clearly indicates the module name used for dependency injection.

---

41-48: Struct Fields in ModuleInputs Are Well-Defined

The ModuleInputs struct fields are properly declared with clear types, and the use of optional:"true" tags for CustomSignModeHandlers and CustomGetSigners is correctly applied for optional dependencies.

---

90-93: Correctly Setting Transaction Encoder and Decoder

The BaseAppOption function correctly sets the TxDecoder and TxEncoder, ensuring that transactions are properly encoded and decoded within the application.